UPON PUBLICATION : Changes from draft - ietf - tsvwg - quickstart

This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and at times in the middle of a data transfer (e.g., after an idle period). While Quick-Start is Floyd/Allman/Jain/Sarolahti [Page 1] INTERNET-DRAFT Expires: January 2007 July 2006 designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path and the sender and all of the routers along the path approve the Quick-Start Request. This document describes many paths where Quick-Start requests would not be approved. These paths include all paths containing routers, IP tunnels, MPLS paths, and the like that do not support QuickStart. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start requests could be difficult to approve over paths that include multi-access layertwo networks. This document also describes environments where the Quick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. Floyd/Allman/Jain/Sarolahti [Page 2] INTERNET-DRAFT Expires: January 2007 July 2006 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: Changes from draft-ietf-tsvwg-quickstart-04: * Reformatted references so that "[RFC2581, RFC3390]" is instead "([RFC2581], [RFC3390])", to eliminate bug reports from the idnits tool. From feedback from Dan Romascanu. * Rephrased beginning of second paragraph in the Abstract. From feedback from James Polk. Changes from draft-ietf-tsvwg-quickstart-03: * Added a discussion of the lower limit of the rate request of 80 kbps, from feedback from Gorry Fairhurst. * Added the QS Nonce to the QS Approved Rate. From feedback from Gorry Fairhurst. * Moved the Related Work section to the appendix. From feedback from Gorry Fairhurst. Changes from draft-ietf-tsvwg-quickstart-02: * Some general editing. * Said that if the receiver receives a Quick-Start Request with a rate of zero, then the receiver SHOULD NOT send a Quick-Start response. And that if the sender receives an acknowledgement of its packet with no Quick-Start response, then the sender MUST assume that the request was denied, and send a Report of Approved Rate with a rate of zero. * Said that if a Quick-Start packet is dropped or marked, the sender should not make more Quick-Start requests in this connection. * Said that the Quick-Start Request SHOULD be sent on a packet that requires an acknowledgement, e.g., a SYN, SYN/ACK, or data packet. * Made changes to the section on "TCP: A Quick-Start Request in the Middle of a Connection". * Added that if the TCP host is going to use the successful Quick-Start Request, it MUST start using it within one Floyd/Allman/Jain/Sarolahti [Page 3] INTERNET-DRAFT Expires: January 2007 July 2006 round-trip time of receiving the Quick-Start Response, or within three seconds, whichever is smaller. * Added a stronger applicability statement, in the abstract and in Section 10 on "Implementation and Deployment Issues". From feedback from the working group. * Added a section about MPLS. From feedback from Mitchell Erblichs. * Strengthened the language of the difficulties presented by multi-access links. * Added a discussion in Section 10.3 about the deployment of Quick-Start on single-hop paths. From feedback from Mitchell Erblichs. * Clarified that the "router" function of approving Quick-Start requests includes the IP-layer processing at the sender. * Clarified in Section 3.3 on "Processing the Quick-Start Request at Routers" that this document standardizes only the semantics of Quick-Start, and not the specific algorithms for processing Quick-Start requests at routers. * Clarified in Section 3.3 on "Processing the Quick-Start Request at Routers" that a router will have to consider the previous Quick-Start requests in approving a new one. * In Section 9.3 on "Quick-Start with QoS-enabled Traffic", which says that routers are free to take into account the diff-serv codepoint in considering QS requests, clarified that routers are also free to take into account their own understanding of priorities. * Added the Temporary bit to Appendix on "Possible Additional Uses for the Quick-Start Option". Clarified that the Quick-Start mechanism is not designed to help routers achieve full link utilization. * Editing from feedback from Gorry Fairhurst. Changes from draft-ietf-tsvwg-quickstart-01: * Added a citation to SPAND: Speeding Up Short Data Transfers. * Added a sentence in Section 8.1 on "Implementation Issues for Processing Quick-Start Requests" about multi-access links. Floyd/Allman/Jain/Sarolahti [Page 4] INTERNET-DRAFT Expires: January 2007 July 2006 * Mentioned the IP Router Alert option, RFC 2113, in Appendix. * Added a discussion of lower-than-best-effort service. * Added a few sentences about the requirements for randomness in the nonce. * Changed the name of the option from the Quick-Start Request Option to the Quick-Start Option. * Changed the semantics of the Reserved field to the Function field, adding that a Quick-Start option is only interpreted as a request if this field is zero. * Changed the "Reporting Approved Rate" option from a "Possible Use" in Appendix to a required use in Section 3.1, to allow routers and receivers some protection against misbehaving senders. * Changes from feedback from Bob Briscoe: Added Appendix about Sections 1-3 of Bob Briscoe’s document. Added a clarification that the approval of a Quick-Start request at a router does not affect the treatment of the subsequent arriving Quick-Start data packets. Added the one-way hash function as an alternate implementation for the QS Nonce. Clarified the phrase "incrementally deployable", adding the following: "We note that while Quick-Start is incrementally deployable in this sense, a Quick-Start request can not be approved for a particular connection unless both end-nodes and all of the routers along the path have been configured to support Quick-Start." Clarified semantics about additional rate. Said that when denying a rate request, the router may in the future use the QS Nonce field to report an error code. Add Bob’s suggestion from Section 4.4 as an alternate possible rate encoding. Made changes suggested in Section 5.1.3 of Bob’s paper, including saying that the router should decrement the QS TTL by the same amount that it decrements the IP TTL (on the off chance that it decrements the IP TTL by more than one). Fixed nits. Changes from draft-ietf-tsvwg-quickstart-00: * Added a 30-bit QS Nonce. Based on feedback from Guohan Lu and Gorry Fairhurst (and deleted the text about a possible four-bit QS nonce). * Added a new section "Quick-Start and IPsec AH", based on feedback from Joe Touch and David Black. * Revised "Quick-Start in IP Tunnels" Section, based on feedback Floyd/Allman/Jain/Sarolahti [Page 5] INTERNET-DRAFT Expires: January 2007 July 2006 from Joe Touch and David Black. * Added a section about "Possible Uses for the Reserved Fields". * Changes from feedback from Gorry Fairhurst: Section 4.4, revised the explanation for reducing the congestion window when the first ACK for a Quick-Start packet is received. Section 6.4, deleted the last sentence. Minor editing changes. Revised Section 4.6.2 to say that sender SHOULD send one packet with an initial RTO of three seconds. Revised Section 4.6.3 to say that the TCP sender SHOULD use an initial RTO setting of three seconds. Added text to Section 6.2 on Multiple Paths, discussing multi-path routing. Clarified about GPRS round-trip times. Clarified about PMTUD and the first window of data. A small reorganization, rearranging sections. * Changes from feedback from Martin Duke: Revised text about the size of QS requests. Added some text to Section 4.1, about when to send QS requests. Changes from draft-amit-quick-start-04.txt: * A significant amount of general editing. * Because the Rate Request field only uses four bits, specified that the other four bits are reserved, and talked about a possible use for them. This is discussed in a new section on "A Rate-Reduced Nonce?" * Specified that a Quick-Start-capable router denying a request SHOULD delete the Quick-Start option, and if this is not possible, SHOULD zero the QS TTL and the Rate Request fields. * Made the following change: If the Quick-Start Response is lost in the network, it is not retransmitted. * For PMTUD, in Section 4.6, added a suggestion to send one large packet in the initial window for PMTUD, and to send the other packets at 576 bytes. * Added a paragraph to Section 4.6.3 on retransmitted SYN packets, saying they should use an RTO of three seconds and a new ISN on the retransmitted SYN packet. * Added that "TCP SHOULD NOT use Quick-Start" after an application-limited period at this time, in Section 4.1, in addition to the old sentence that this "requires further thought and investigation". * Added an appendix on "Possible Router Algorithm". * Moved the section on "Quick-Start with DCCP" to the appendix. * Name changed from draft-amit-quick-start-04.txt to draft-tsvwg-quickstart-00.txt. Changes from draft-amit-quick-start-03.txt: Floyd/Allman/Jain/Sarolahti [Page 6] INTERNET-DRAFT Expires: January 2007 July 2006 * Added a citation to the paper on "Evaluating Quick-Start for TCP", and added pointers to the work in that paper. This work includes: Discussions of router algorithms. Discussions of sizing Quick-Start requests. * Added sections on "Misbehaving Middleboxes", and on "Attacks on Quick-Start". Changes from draft-amit-quick-start-02.txt: * Added a discussion on Using Quick-Start in the Middle of a Connection. The request would be on the total rate, not on the additional rate. * Changed name "Initial Rate" to "Rate Request", and changed the units from packets per second to bytes per second. * The following sections are new: The Quick-Start Request Option for IPv6 Quick-Start in IP Tunnels When to Use Quick-Start TCP: Responding to a Loss of a Quick-Start Packet TCP: A Quick-Start Request for a Larger Initial Window TCP: A Quick-Start Request after an Idle Period The Quick-Start Mechanisms in DCCP and other Transport Protocols Quick-Start with DCCP Implementation and Deployment Issues Design Decisions * Added a discussion of Kunniyur’s Anti-ECN proposal. * Added a section on simulations, with a brief discussion of the simulations by Srikanth Sundarrajan. Changes from draft-amit-quick-start-01.txt: * Added a discussion in the related work section about the possibility of optimistically sending a large initial window, without explicit permission of routers. * Added a discussion in the related work section about the tradeoffs of XCP vs. Quick-Start. * Added a section on "The Quick-Start Request: Packets or Bytes?" Changes from draft-amit-quick-start-00.txt: * The addition of a citation to [KHR02]. * The addition of a Related Work section. * Deleted the QS Nonce, in favor of a random initial value for the QS TTL. Floyd/Allman/Jain/Sarolahti [Page 7] INTERNET-DRAFT Expires: January 2007 July 2006